Appl. No. 10/779,984 

Response dated March 5 , 2007 

Reply to Office action of December 11, 2006 

REMARKS/ARGUMENTS 

In response to the Examiner's Office Action of December 11, 2006, Applicants will now 
make the following considerations and arguments. 

. In regard to Examiner's statements regarding the rejection under 35 U.S.C. 112 on the 
basis that the specification has terms which omitted certain characters leaving certain terms to be 
unclear or unexact. Applicants would wish to indicate that the specification provided by 
Applicant was fully and properly printed and there were no omissions or missing characters. 

Apparently the crux of the problem resides within the U. S. Patent Office in its attempt to 
transfer the printed pages into electronic format. 

In regard to this matter the undersigned has called the Patent Office on January 24, 2007 
and a conversation was had with Examiner Dieu-Minh T. Le. The Examiner has acknowledged 
over the phone that the errors in the specification (as rejected in the Office Action of December 
11, 2006) were apparently due to the scanning process at the U.S. Patent Office. As a result the 
undersigned has indicated that a copy will be sent to the Examiner of the original specification as 
per the instructions of the Examiner given over the telephone. Accordingly, please find attached 
a new original copy of the specification for this docket 03-027. 

The Examiner has rejected claims 1 - 14 under 35 U.S.C. 103(a) as unpatentable over the 
Trotter reference (US2004/0123303) in view of the Robb reference (US2003/0120502). 

As will be noted in the amended claims, the previous claim 1 has now been incorporated 
with the previous claims 2, 3, and 4. 

Likewise, the former independent claim 5 has now been amended to include the prior 
claims 8, 10, 12, 13, as will be indicated in the amended claims. Now in this regard with the 
amended claims, Applicants will make some comments in regard to the citations made by the 
Examiner regarding some of the prior claims which were originally filed. 

It will first be noticed regarding Applicant's claim 1 that the use of a "soaker application" 
is not something that is taught or shown in either of the Trotter or the Robb reference. 

In regard to claim 1, the clause (a), the Examiner has cited the Trotter abstract plus 
Trotter column 3 and claim 1, regarding the consumption of a predetermined amount of memory 
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at a predetermined rate. It should be noted that Trotter refers to the use of a JVM or Java Virtual 
Machine by many remote users. It is noted here that in Trotter, the use of the JVM imposes 
limits on the memory usage by all users of the JVM. These limits are imposed by specifying a 
maximum heap size limit. This provides a disadvantage that the single JVM limit constrains all 
the potential users of a multi-user JVM to the same level and thus makes it possible for one user 
to mount a denial of service attack to all users simply by overconsuming memory in the single 
JVM unit. The statements in Trotter 0004 and 0005 do not provide for consuming a 
predetermined amount of memory at a predetermined rate. 

Now in regard to claim 1 clause (b) — on setting a memory threshold value to memory 
consumption, the Examiner has cited Trotter column 3 paragraph 0055. This paragraph 0055 
involves the use of threads which are not stopped while in the process of making updates to share 
the sources. A thread pull could be maintained and used to drive the successive run methods. 
The standard Java syntax can use the semantics of the run method to include the statement 
"must not run for more than X ms (milliseconds)". 

This paragraph 0055 does not teach Applicant's clause (b) for setting a memory 
threshold value to memory consumption. 

The Examiner has argued that the Trotter reference can be modified by Robb citing Robb 
column 15 paragraph 0138-0139. There is nothing in these two paragraphs 0138 and 0139 of 
Robb which teaches the setting of a memory threshold value to memory consumption. Robb 
talks about horizontal and vertical hardware scalability in addition to software scalability where 
if a horizontally scalable processor fails, the load balancer detects the failure condition and sends 
the next service request to the next available processor until the failed processor is replaced. 

Further, in Robb paragraph 0139, the only relevant item seems to be the statement 
that these applications run upon demand and do not over-consume resources, as 
for example, a servlet does. 

Now returning to the original claim 2 (which now is included within claim 1), we see the 
clause (bl) — initiating a failover action when said memory threshold is reached so that the 
processing is shifted to another node in the system. 
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Here Examiner cited Trotter column 1 paragraph 0023. Here Trotter discusses 
identification of the point at which the constraining of memory is performed and this involves 
periodically sampling the value of Runtime.Total Memory ( ) and imposing the constraint when 
it reaches a predetermined value. Thus paragraph 0023 does not teach initiating a failover action. 

Then in the Trotter paragraph 0049, the only relevant point here is where he states: — a 
denial of service opportunity. To avoid the situation it is assumed the JVM will itself be able to 
impose limits on the size of large objects allocated by the current thread — . 

Further in regard to clause (bl) of the original claim 2, Examiner cites the Robb reference 
column 130138 and 0139. Here Robb talks of — horizontal scalability refers to adding 
components such as servers to add system capacity ... in addition horizontal scalable processes ... 
may be managed as clusters. If a horizontally scalable processor fails, the load balancer detects 
the failure condition and sends the next service request to the next available processor until the 
failed processor is replaced. — This however can be considered use of a failover action in a 
different context than that of Applicants. 

In regard to Robb paragraph 0128, this is a discussion of levels of security to the 
applications that are accessed through the access of servers. 
Regarding Applicant's original claim 3 clause (al) — setting a rate of memory 
consumption according to a selected choice of low, medium, high, or super high level of memory 
consumption and shared memory resources. 

Here the Examiner has cited the Trotter reference at column 3 in claim 1, plus Trotter 
column 1 paragraph 004-005 and also column 3 - 0055, 0057. Here it is noted that paragraphs 
0004 and 0005 discuss identifying the objects created by a given user and thus determine which 
user or users are over-consuming memory. 

Then at Trotter paragraph 0055 — here is the only relevant Trotter statement 
involves ... this whole approach makes no change to standard Java syntax but 
obviously changes the semantics of the run method to include the statement "must 
not run for more than X ms (milliseconds)" ... it is worth noting, providing the 
threads are fairly well behaved and don't consume large amounts of memory, the 
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None of these citations can teach (as indicated by Examiner) the means for 
setting the rate with choices of low, medium, higher, super high levels of 
memory consumption. 

Now in regard to amended claim 1, Applicant's original claim 3 clause (a2) — selecting a 
time interval within which said selected rate of memory consumption will operate. — Here the 
Examiner has cited Trotter column 3 paragraph 0054, and Trotter discusses the use of threads. 
For example Trotter says in paragraph 0054 — a second option is to impose some limit on the 
length of time a run method can execute. Any thread which fails to complete within that limit 
could simply be stopped with using a Thread.Stop. Typically all the user's threads would be 
stopped if any of them caused such a problem — . 

This is a very odd way of correlating to Applicant's way of selecting a time 
interval with Trotter's use of a means for stopping threads (Thread.Stop). 
Now regarding Applicant's original claim 4 clause (a3) — utilizing a MPEG digital 
stream of data from a movie as a source of data to be consumed by memory resources — . 

Here the Examiner has cited the Robb reference column 13 paragraphs 0138, 0139 and 
0142. Here it will seen that paragraphs 0138 and 0139 talk about horizontal and vertical 
hardware in addition to software scalability. There is nothing stated regarding the use of a 
MPEG digital stream of data to be consumed by memory resources. 

The Robb paragraph 0142 discusses the Robb Fig. 10 to show a top model of the 
processing path from Corporate Customer to Legacy Systems. There is nothing 
here to teach utilizing a digital stream of data from a movie as a source of data to 
be consumed by the memory resources. 
Further regarding the original claim 4 clause (a3), Examiner has cited the Robb claims 27, 
28, and 36. Here claim 27 of Robb involves a messaging technology which supports point-to- 
point and publishes subscribed type messaging with varying bandwidths to provide varying 
quality of service levels. 

Likewise claim 28 involves the rules of a process of workflow 
management which are defined centrally and stored in a rules engines. 
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Likewise in claim 36, the Robb claim involves Service Level Agreement (SLA) 

management supported through application monitoring and reporting as part of 

Service Level Agreement management. 
In no way can it be seen that these claims can teach Applicant's original claim 4 clause 
(a3) for utilizing a MPEG digital stream of data from a movie as a source of data to be 
consumed by said memory resources. 

In regard to Applicant's original claim 5, Examiner has indicated that the Trotter 
reference does not show the (i) load balancing operation or the (ii) soaking application — but 
that Trotter does show a system for managing memory and for setting threshold values from 
memory citing Trotter column 3 paragraph 0055 and Trotter's claim 1. 

It will be seen that in paragraph 0055 of Trotter, the only possibly relevant 

statement there is — 

... that the semantics of the run method to include the statement "must not run for 
more than X ms." It is worth noting that, providing the threads are fairly well- 
behaved and don't consume large amounts of memory, the JVM heap will stay 
below some threshold value... . 
Applicant's contend that this does not teach Applicant's clause (al) of claim 5 — means 
to select the rate of memory consumption per a selected unit of time. — 
Examiner cites Trotter clause 0054 which states that — a second option is to impose 
some limit on the length of time a run method can execute. Any thread which fails to complete 
within that limit could simply be stopped using Thread.Stop. 

This paragraph 0054 does not teach or show the substance of Applicant's 
claim 5, clause (a2) for means to recognize a threshold value of memory 
loading which matches the limitations of the shared memory resources. 
Further, in regard to Applicant's original claim 5, the Examiner has cited the Robb 
reference as providing a management system. However, Robb only discusses this in terms of 
generalities and not specifics. Examiner cites Robb column 13, paragraphs 0138 and 0139. 
Here paragraph 0138 discusses horizontal and vertical hardware stability and in addition to 
software scalability. Then the paragraph in Robb 0139 discusses software scalability and 
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dynamic management of applications... where Robb states these applications run upon demand 
and do not over-consume resources as for example a servlet does. ... According to one 
embodiment of the invention (Robb) software components use EJB container managed 
persistence service beans. 

These two paragraphs of Robb do not specifically show the elements provided by 

Applicant regarding (i) selecting the rate of memory consumption and (ii) means 

to recognize the threshold value. 
Further regarding Applicant's original claim 6 clause (ala) which involves — means to 
supply a digital data stream for input to said shared memory resources. — There is nothing 
specifically shown in either of the Trotter or the Robb references. 

In Applicant's original claim 6 clause (alb) which involves — means to pause said 
digital input to said shared memory resources — here Examiner has cited Trotter column 1 
paragraphs 0013 and 0014 plus claim 1 of Trotter. 

Paragraphs 0013 and 0014 of Trotter only make a rather vague comment that ... 

constrains the user memory footprint preferably includes stopping threads running 

on behalf of the user. — This refers to a specialized machine called a Java 

Virtual Machine. 

This certainly does not teach Applicant's clause (alb) of claim 6 on — a means to 
pause the digital input to the shared memory resources. 

Likewise Applicant's original claim 6 clause (ale) which involves — - means to resume 
the digital input stream from the exact frame on which it had paused or stopped — there is 
nothing in the cited references that has been cited to indicate this feature. 

Regarding Applicant's original claims 7 and 8 5 there is nothing shown in Trotter's claim 
1 and paragraphs 0004, 0005, 0055, and 0057 which indicate Applicant's teaching — for the 
choice of loading speed rates of low, medium, high or super speed rates per second. 

In regard to Applicant's original claim 7 where Examiner has cited the Robb reference 
clauses 0138, 0139, 0036 and 0142 plus Robb claims 27, 28, and 36. It will be noted that none 
of these citations can indicate Applicant's clause (alab) involving selection means for choosing 
loading speed rates at low, medium, high or super speed rates per second. 
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The Examiner has stated that Trotter paragraph 0054 indicates that Trotter sets the rate of 
consumption. — However, the Trotter clause 0054 involves imposing some limit on the length of 
time a run method can execute so that any thread which fails to complete with that limit could 
simply be stopped using Thread.Stop. 

This is not the same as Applicant's system for setting the rate of 
consumption as indicated in Applicant's original claims 6, 7, and 8. 
Further in theTrotter claim 1, there is a statement regarding — determining that the total 
memory footprint of the system has reached a predetermined level ... determining a user memory 
footprint by calculating the memory footprint of at least one object and ... constraining the user 
memory footprint such that the total memory footprint of the system is limited. 

This certainly does not teach or indicate Applicant's means to supply a 
digital data stream or Applicant's means to pause and stall said digital 
input and Applicant's means to resume a digital input stream from the 
exact frame on which it had been paused or stopped. 
Nor does Trotter teach Applicant's selection means for choosing the 
loading of speed rates of low, medium, high or super speed. 
It may be remarked, that in a peripheral sense, there are some situations in both the 
Trotter reference and in the Robb reference where certain factors are used to constrict memory 
consumption, however these do not follow the defined and stated techniques as shown by 
Applicants. 

Further, it is seen that the Examiner is using hindsight by taking aspects of the Trotter 
reference and adding to this, the aspect of the Robb reference in order to then amalgamate these 
two references in order to recreate the invention of Applicants. 

It is inappropriate and improper to take bits and pieces from one area of technology and 
combine them with bits and pieces of another area of technology and then use these into an 
amalgamated form in order to recreate, using hindsight, the invention of Applicants. 

With the newly-amended claims and with the specifically defined functionality shown in 
these claims, it will be recognized that neither the Trotter reference or the Robb reference nor the 
combination can encompass and teach the entirety of the features defined in these claims. 
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It should be understood that a claim must be considered as a whole in its entirety and may 
not be invalidated if only bits and pieces of this are known in the prior art. In this regard the 
Examiner is requested to take another look and view the newly-amended claims in their entirety 
as a whole and subsequently provide a timely Notice of Allowance therefor. 

Respectfully submitted, 
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